前面一系列的文章有介紹過 UI 測試和 API 測試，普遍來說，因為 UI 的 Automation Test 有界面可見，更接近人手的操作，學習下來比較簡單，所以目前大多數的公司都會取向先導入 UI 的 Automation Test。

然而參看著名的 自動化測試金字塔，會看到取向應該是大量投入 Unit Test，再來是 API Test，最後才是 UI Test。那是因為愈接近底層的測試，愈容易瞄準問題作修正，測試速度亦相對較快。

Unit Test 單元測試：一般由開發人員負責，測試程式邏輯是否正確，屬於白箱測試。需要熟知程式碼的內容，所以一般較少由 SDET 負責開發。當然，若你有能力有權限去檢閱開發程式，也是可以協助開發單元測試的。

圖片來源： https://cloud.tencent.com/developer/article/1831196

然而，Unit Test 的測試內容太細緻，在開發過程同時需要大量投入時間去開發 Unit Test 這件事並不夠 “人性” 。特別是針對迭代速度很快，時程很趕的案子根本是天荒夜談，所以會偏向著重 API Test，所以自動化測試的比例模型都有所改變。而作為自動化測試工程師更適合在這位置切入，協助開發 API Test 測試。

因此，針對從 0 開始作自動化測試的導入，會分為 4 個階段。

1. 前置作業

• 提供穩定的測試環境，系統資源充足
• 需要準備一份完整的 API 文件，詳細需要的內容已在 Day 20: 認識 API 測試 提及。
• Database 讀取的權限，若有相關文件更佳 (I.e. ERDiagram)
• 前端的 Web Element 建設自動化測試專用的 ID

2. 自動化測試的流程的基礎建設

• 基本的測試專案框架設計
• 並行測試的應用
• 設計測試報告內容
• 應用 CI / CD 工具把整個測試流程串接

3. 導入 API 測試

• 撰寫詳細 API 的邏輯測試，需要跟 Database 的資料作比對
• 若部分邏輯是由前端處理，則需要用 UI 測試來覆蓋。

4. 導入 UI 測試

• 只測試 Happy Path 的正常使用流程，確認 UI 的元件都能正常運作。
• 並非測試重點的步驟可以 API 取代要加速整個測試速度

自動化測試工程師的工作模式

對大部分公司目前的理解，大概分 2 種模式：

• 自動化測試工程師 為一個獨立團隊，作 中央處理 各團隊的自動化測試的工作。

  • 優點：
    • 可以專心做開發測試的工作，效率較高。
    • 人手不足以分發到各團隊時的選擇，比較可以照顧到各團隊的需要。
  • 缺點：
    • 對測試內容了解有限，未必能很精準寫出團隊需要的測試。
    • 都需要在整個開發流程結束才可以開始開發自動化測試。

• 自動化測試工程師會 分散在各個團隊 ，跟著開發流程 為團隊執行 自動化測試的工作。

  下圖以 Scrum Team 為例，自動化測試工程師於每個 Sprint 的工作：

  

  • 優點：
    • 更透徹的理解專案的內容，從設計開始參與，從 靜態測試 Static Testing 開始做起，可以更早發現問題，省去不必要的開發成本。
    • 在開發過程中就可以著手開發自動化測試，與手動測試的人員互相配合，可減輕手動測試的工作量。
  • 缺點：
    • 自動化測試的工作更多樣化，門檻較高
    • 需要的人手較多才能滿足各團隊的需求

靜態測試 Static Testing

主要是在不執行實際程式碼的情況下，對軟體的設計文件、配置文件、程式碼等進行分析和檢查，以發現潛在的問題、錯誤和不一致性。

在開發前期測試工程師主要可協助檢示需求文件和系統設計以及早發現問題、提高團隊合作，並有助於減少後續測試和維護的成本。

以上 2 種模式較為常見，實際還是會根據公司狀況調整。

自動化測試的好處

到最後才說這個會不會有點太晚？但我相信想要學習自動化測試的你，大概也聽說過它有什麼好處，只是還沒有真正的體悟到。現在學了這麼多，回頭來看，為什麼要做自動化測試？不外乎 2 個重點 降低成本 和 提高測試品質 。

1. 降低成本
   • 更深入底層的測試，及早發現，及早修正，大幅降低修正成本
   • 減少 Regression Test 的手動測試時間
2. 提高測試的品質
   • 利用程式進行測試的靈敏度高
   • 有助於捕捉沒想到的錯誤 （I.e. 改 A 壞 B 的問題)
   • 更快的測試周期，有助於系統重構

但要做到這 2 個效果，也要有好的測試程式品質，測試的設計流程。

以前常聽說做自動化測試，學學怎樣寫 Script 就好，能跑就好了，但往往因為對整個測試專案的不理解，而產生大量的 Flaky Test，接下來消耗的維運時間，都足以使用手動測試完成了，讓大家對自動化測試產生懷疑，它真的可以降低成本嗎？

所以我非常強調作為自動化測試工程師，都必須要有基本的工程能力。因此在去年在 AppWorks School 設計了一個自動化測試工程師的學習課程，以自動化測試為目標，用最短的時間幫學員們補足作為工程師的基本能力。這次參加鐵人賽剛好作為過去一年的總結，在與學員互動的過程，更了解大家在學習的過程會遇到什麼卡點，整理下來成為這 30 篇文章。

當然這些其實都只是學習的起步，路還很漫長，至少還要學習的有：

1. APP 的測試
2. Docker & K8S 的應用
3. 了解各種的測試框架
4. 了解各種的 CI / CD 工具
5. 雲端的技術應用 (AWS / GCP) 等

然後就是實戰經驗的累積了。

需要有心理準備作為工程師就是要終身學習，技術都發展太快，沒有跟上就落伍了。

自動化測試將會是未來的趨勢，現在就像十多年前開發技術還沒普及化時，要慢慢推行各種的系統化，到現在什麼都已經系統化。同樣，也可預想未來的十年，自動化測試普及，可取代繁複的人手操作，帶來更快的測試周期，更好的產品品質，推進科技的發展。

最後，感謝看到最後一篇的你，第一次寫技術文章，或許會有不足之處，有任何問題都歡迎私訊留言討論，有緣再會～